Conclusiones¶

Problematica. Hay MVPs muy complejos, que no tienen pilotaje.
Todos los grupos DEBEN tener pilotaje (usuarios reales usando la aplicación).
Debe haber una utilización real para que realmente esté con éxito.
CUIDADO con eso. Deberían estar todas las funcionlidades.
Deben estar el coste con respecto al pilotaje.
Cosa explícita, saber que el feedback es una cosa y otra lo que hacen las pruebas los profesores.
Deben tener una funcionalidad preparada.
Feedback de presentación no es todo.
Producción. Deben estar bien definidos. Versionado de aplicaciones más claro.
Lo que entregemos tiene que estar en producción, estable y estará valorada.
No es aceptable diferentes versiones, desplegar una versión v1, v2 ...
Ambas versiones deben estar desplegadas.
Lo ideal, v1, v2 y v3 claramente definidas.
URLs diversas son válidas. ¿En apartado de notas? Sí, siempre que quede claro.
¡¡Testing!! Todos los equipos tienen testing, deberían estar encargados de que llegue con calidad. No es justificable que haya si no llega con calidad. Profesores no son el equipo de testing.
Fracaso en el próximo Sprint es no usuarios reales, no se haya hecho un análisis del feedback ni estudiado el tema de costes.
Plan de pilotaje, ¿Diferentes posibles usuarios se tendrán en cuenta? En este punto, encontrar personas reales no debería ser gran problema porque puede suponer un sector de mercado.
Una cierta necesidad temporal es rentable, pero debería haber (sin más). ¡Estudio de mercado!
Un proyecto fallido es del que más se aprende. Un proyecto con éxito aparente no es una buena forma de aprendizaje. Si se ha hecho todo lo posible que se ha intentado de mejora continua, entonces hay un éxito aunque no tanto por el resultado. Es decir, el resultado del producto no es un automático suspenso. Los fallos no son malos, aprender es lo importante aqui.
Lanzar el proyecto fuera de Sevilla es una posibiilidad, España, Europa o mundial es una alternativa que hay que tener en cuenta.